As computers and software have become more powerful, developers and vendors are providing new and more complex features to increasingly sophisticated users. Moreover, the proliferation of high-speed internet access has enabled developers and vendors to offer users and customers entirely new and even more complex services over the internet through the use web services, web applications, and application servers.
Such services, when required to support a large-scale user base or to provide a high-level of availability, are often provided in a data center using one of many service-oriented architectures (SOA). Implementation of an SOA requires tools as well as run-time infrastructure software, which is collectively referred to as an SOA implementation framework. Such frameworks have unique requirements at both the tools and infrastructure levels. These include a distributed event-enabled architecture, flexibility via service-enabled processes, enterprise standards support (fault tolerance, reliability, and scalability), security in distributed environment, visual process composition and monitoring, and support for rapid process changes and process development to enable providing new and improved user services.
For many reasons (e.g., fault tolerance, reliability, and scalability) user account entities may be distributed across many architectural components, which may be partitioned into several smaller sets. For example, in a system with thousands of accounts, each with their own set of data, it may be desirable to spread such accounts among several repositories. Each repository may hold one or more account.
However, each level of scope (e.g. repository and account) has its own state that can apply to its children. For example, if an entire repository is taken down for maintenance, all accounts in that repository are implicitly unavailable. On the other hand, if a single account is deactivated, it does not affect the state of the repository or the other accounts in the repository.
A problem can arise in the event that a process attempts to change the state of a system entity (e.g., repository, account, etc.) to an inconsistent state. As a real world example, it should not be possible for a person to change state from being “married” to being “single, never married”. The only valid states after “married” might be “divorced”, “widowed”, or “deceased”. Likewise, a user account should not be able to accessed (e.g., in an account available state) if its respective repository is taken down for maintenance (e.g., in a repository unavailable state). This problem is further exacerbated as the level of system scales to support more users and as the degree of architectural component distribution increases, because of the administrative overhead required to coordinate an increasing number of distributed components. As a result, access to the state needs to be tightly controlled in an efficient and reliable manner.
One approach to maintaining consistent states of a service's entities could be to directly poll an entity for its status and require that either the requestor (e.g., external clients, or tools) or each entity verify any requested state change, which would require direct coordination among the service's entities and the requester. However, with such a distributed access and control model, as the number of distributed components increases to support more users or to support reliability and redundancy goals, the overhead associated with such a model can become excessive. Additionally, the required intra-entity coordination among distributed components can be complex and subject to increasing conflicts as the system scales. Furthermore, the maintenance flexibility of such an approach may be hampered because of the need to manually account for the various intra-entity dependencies.
Accordingly, in consideration of the need to ensure that the system entity state is consistent and all state transitions are valid, it would be desirable to provide an efficient and reliable mechanism to control access to the system state and ensure valid state transitions of system entities.